home *** CD-ROM | disk | FTP | other *** search
/ Personal Computer World 2007 September / PCWSEP07.iso / Software / Linux / Linux Mint 3.0 Light / LinuxMint-3.0-Light.iso / casper / filesystem.squashfs / usr / share / doc / gcc-4.1-base / README.Bugs < prev    next >
Encoding:
Text File  |  2007-03-02  |  10.8 KB  |  305 lines
  1. Reporting Bugs in the Debian/GNU GNU Compiler Setup
  2. ===================================================
  3.  
  4. Before reporting a bug, please
  5. ------------------------------
  6.  
  7. - Check that the behaviour really is a bug. Have a look into some
  8.   ANSI standards document.
  9.  
  10. - Check the list of well known bugs: http://gcc.gnu.org/bugs.html#known
  11.  
  12. - Try to reproduce the bug with a current GCC development snapshot. For
  13.   Debian GNU/Linux you can get a recent development snapshot from the
  14.   gcc-snapshot package in the unstable distribution.
  15.   See: http://packages.debian.org/gcc-snapshot
  16.  
  17. - Try to find out if the bug is a regression (an older GCC version does
  18.   not show the bug).
  19.  
  20. - Check if the bug is already reported in the bug tracking systems.
  21.  
  22.     Debian:   http://bugs.debian.org/debian-gcc@lists.debian.org
  23.     Upstream: http://gcc.gnu.org/bugzilla/
  24.  
  25.  
  26. Where to report a bug
  27. ---------------------
  28.  
  29. Report bugs found in the packaging of GCC to the Debian bug tracking system.
  30. See http://www.debian.org/Bugs/ for instructions (or use the reportbug
  31. script).
  32.  
  33. Debian's current policy is to closely follow the upstream development and
  34. only apply a minimal set of patches (which are summarized in the README.Debian
  35. document).
  36.  
  37. If you think you have found an upstream bug, you did check the section
  38. above ("Before reporting a bug") and are able to provide a complete bug
  39. report (see below "How to report a bug"), then you may help the Debian
  40. GCC package maintainers, if you report the bug upstream and then submit
  41. a bug report to the Debian BTS and tell us the upstream report number.
  42. This way you are able to follow the upstream bug handling as well. If in
  43. doubt, report the bug to the Debian BTS (but read "How to report a bug"
  44. below.
  45.  
  46.  
  47. How to report a bug
  48. -------------------
  49.  
  50. There are complete instructions in the gcc info manual (found in the
  51. gcc-doc package), section Bugs.
  52.  
  53. The manual can be read using `M-x info' in Emacs, or if the GNU info
  54. program is installed on your system by `info --node "(gcc)Bugs"'. Or see
  55. the file BUGS included with the gcc source code.
  56.  
  57. Online bug reporting instructions can be found at
  58.  
  59.     http://gcc.gnu.org/bugs.html
  60.  
  61. [Some paragraphs taken from the above URL]
  62.  
  63. The main purpose of a bug report is to enable us to fix the bug. The
  64. most important prerequisite for this is that the report must be
  65. complete and self-contained, which we explain in detail below.
  66.  
  67. Before you report a bug, please check the list of well-known bugs and,
  68. if possible in any way, try a current development snapshot.
  69.  
  70. Summarized bug reporting instructions
  71. -------------------------------------
  72.  
  73. What we need
  74.  
  75. Please include in your bug report all of the following items, the
  76. first three of which can be obtained from the output of gcc -v:
  77.  
  78.     * the exact version of GCC;
  79.     * the system type;
  80.     * the options given when GCC was configured/built;
  81.     * the complete command line that triggers the bug;
  82.     * the compiler output (error messages, warnings, etc.); and
  83.     * the preprocessed file (*.i*) that triggers the bug, generated by
  84.       adding -save-temps to the complete compilation command, or, in
  85.       the case of a bug report for the GNAT front end, a complete set
  86.       of source files (see below).
  87.  
  88. What we do not want
  89.  
  90.     * A source file that #includes header files that are left out
  91.       of the bug report (see above)
  92.     * That source file and a collection of header files.
  93.     * An attached archive (tar, zip, shar, whatever) containing all
  94.       (or some :-) of the above.
  95.     * A code snippet that won't cause the compiler to produce the
  96.       exact output mentioned in the bug report (e.g., a snippet with
  97.       just a few lines around the one that apparently triggers the
  98.       bug, with some pieces replaced with ellipses or comments for
  99.       extra obfuscation :-)
  100.     * The location (URL) of the package that failed to build (we won't
  101.       download it, anyway, since you've already given us what we need
  102.       to duplicate the bug, haven't you? :-)
  103.     * An error that occurs only some of the times a certain file is
  104.       compiled, such that retrying a sufficient number of times
  105.       results in a successful compilation; this is a symptom of a
  106.       hardware problem, not of a compiler bug (sorry)
  107.     * E-mail messages that complement previous, incomplete bug
  108.       reports. Post a new, self-contained, full bug report instead, if
  109.       possible as a follow-up to the original bug report
  110.     * Assembly files (*.s) produced by the compiler, or any binary files,
  111.       such as object files, executables, core files, or precompiled
  112.       header files
  113.     * Duplicate bug reports, or reports of bugs already fixed in the
  114.       development tree, especially those that have already been
  115.       reported as fixed last week :-)
  116.     * Bugs in the assembler, the linker or the C library. These are
  117.       separate projects, with separate mailing lists and different bug
  118.       reporting procedures
  119.     * Bugs in releases or snapshots of GCC not issued by the GNU
  120.       Project. Report them to whoever provided you with the release
  121.     * Questions about the correctness or the expected behavior of
  122.       certain constructs that are not GCC extensions. Ask them in
  123.       forums dedicated to the discussion of the programming language
  124.  
  125.  
  126. Known Bugs and Non-Bugs
  127. -----------------------
  128.  
  129. [Please see /usr/share/doc/gcc/FAQ or http://gcc.gnu.org/faq.html first]
  130.  
  131.  
  132. C++ exceptions don't work with C libraries
  133. ------------------------------------------
  134.  
  135. [Taken from the closed bug report #22769] C++ exceptions don't work
  136. with C libraries, if the C code wasn't designed to be thrown through.
  137. A solution could be to translate all C libraries with -fexceptions.
  138. Mostly trying to throw an exception in a callback function (qsort,
  139. Tcl command callbacks, etc ...). Example:
  140.  
  141.     #include <stdio.h>
  142.     #include <tcl.h>
  143.  
  144.     class A {};
  145.  
  146.     static
  147.     int SortCondition(void const*, void const*)
  148.     {
  149.         printf("throwing 'sortcondition' exception\n");
  150.         throw A();
  151.     }
  152.  
  153.     int main(int argc, char *argv[])
  154.     {
  155.         int list[2];
  156.  
  157.         try {
  158.             SortCondition(NULL,NULL);
  159.         } catch (A) {
  160.             printf("caught test-sortcondition exception\n");
  161.         }
  162.         try {
  163.             qsort(&list, sizeof(list)/sizeof(list[0]),sizeof(list[0]),
  164.                  &SortCondition);
  165.         } catch (A) {
  166.             printf("caught real-sortcondition exception\n");
  167.         }
  168.         return 0;
  169. }
  170.  
  171. Andrew Macleod <amacleod@cygnus.com> responded:
  172.  
  173. When compiled with the table driven exception handling, exception can only
  174. be thrown through functions which have been compiled with the table driven EH.
  175. If a function isn't compiled that way, then we do not have the frame
  176. unwinding information required to restore the registers when unwinding.
  177.  
  178. I believe the setjmp/longjmp mechanism will throw through things like this, 
  179. but its produces much messier code.  (-fsjlj-exceptions)
  180.  
  181. The C compiler does support exceptions, you just have to turn them on
  182. with -fexceptions.
  183.  
  184. Your main options are to:
  185.   a) Don't use callbacks, or at least don't throw through them.
  186.   b) Get the source and compile the library with -fexceptions (You have to
  187.      explicitly turn on exceptions in the C compiler)
  188.   c) always use -fsjlj-exceptions (boo, bad choice :-)
  189.  
  190.  
  191. g++: "undefined reference" to static const array in class
  192. ---------------------------------------------------------
  193.  
  194. The following code compiles under GNU C++ 2.7.2 with correct results,
  195. but produces the same linker error with GNU C++ 2.95.2.
  196. Alexandre Oliva <oliva@lsd.ic.unicamp.br> responded:
  197.  
  198. All of them are correct.  A static data member *must* be defined
  199. outside the class body even if it is initialized within the class
  200. body, but no diagnostic is required if the definition is missing.  It
  201. turns out that some releases do emit references to the missing symbol,
  202. while others optimize it away.
  203.  
  204. #include <iostream>
  205.  
  206. class Test
  207. {
  208.   public:
  209.     Test(const char *q);
  210.   protected:
  211.     static const unsigned char  Jam_signature[4]   = "JAM";
  212. };
  213.  
  214. Test::Test(const char *q)
  215. {
  216.   if (memcmp(q, Jam_signature, sizeof(Jam_signature)) != 0)
  217.   cerr << "Hello world!\n";
  218. }
  219.  
  220. int main(void)
  221. {
  222.   Test::Test("JAM");
  223.   return 0;
  224. }
  225.  
  226. g++: g++ causes passing non const ptr to ptr to a func with const arg
  227.      to cause an error (not a bug)
  228. ---------------------------------------------------------------------
  229.  
  230. Example:
  231.  
  232. #include <stdio.h>
  233. void test(const char **b){
  234.         printf ("%s\n",*b);
  235. }
  236. int main(void){
  237.         char *test1="aoeu";
  238.         test(&test1);
  239. }
  240.  
  241. make const
  242. g++     const.cc   -o const
  243. const.cc: In function `int main()':
  244. const.cc:7: passing `char **' as argument 1 of `test(const char **)' adds cv-quals without intervening `const'
  245. make: *** [const] Error 1
  246.  
  247. Answer from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>:
  248.  
  249. > ok... maybe I missed something.. I haven't really kept up with the latest in
  250. > C++ news.  But I've never heard anything even remotly close to passing a non
  251. > const var into a const arg being an error before.
  252.  
  253. Thanks for your bug report. This is a not a bug in the compiler, but
  254. in your code. The standard, in 4.4/4, puts it that way
  255.  
  256. # A conversion can add cv-qualifiers at levels other than the first in
  257. # multi-level pointers, subject to the following rules:
  258. # Two pointer types T1 and T2 are similar if there exists a type T and
  259. # integer n > 0 such that:
  260. #   T1 is cv(1,0) pointer to cv(1,1) pointer to ... cv(1,n-1)
  261. #   pointer to cv(1,n) T
  262. # and
  263. #   T2 is cv(2,0) pointer to cv(2,1) pointer to ... cv(2,n-1)
  264. #   pointer to cv(2,n) T
  265. # where each cv(i,j) is const, volatile, const volatile, or
  266. # nothing. The n-tuple of cv-qualifiers after the first in a pointer
  267. # type, e.g., cv(1,1) , cv(1,2) , ... , cv(1,n) in the pointer type
  268. # T1, is called the cv-qualification signature of the pointer type. An
  269. # expression of type T1 can be converted to type T2 if and only if the
  270. # following conditions are satisfied:
  271. #  - the pointer types are similar.
  272. #  - for every j > 0, if const is in cv(1,j) then const is in cv(2,j) ,
  273. #    and similarly for volatile.
  274. #  - if the cv(1,j) and cv(2,j) are different, then const is in every
  275. #    cv(2,k) for 0 < k < j.
  276.  
  277. It is the last rule that your code violates. The standard gives then
  278. the following example as a rationale:
  279.  
  280. # [Note: if a program could assign a pointer of type T** to a pointer
  281. # of type const T** (that is, if line //1 below was allowed), a
  282. # program could inadvertently modify a const object (as it is done on
  283. # line //2). For example,
  284. # int main() { 
  285. #   const char c = 'c'; 
  286. #   char* pc; 
  287. #   const char** pcc = &pc; //1: not allowed 
  288. #   *pcc = &c; 
  289. #   *pc = 'C'; //2: modifies a const object 
  290. # }
  291. # - end note]
  292.  
  293. If you question this line of reasoning, please discuss it in one of
  294. the public C++ fora first, eg. comp.lang.c++.moderated, or
  295. comp.std.c++.
  296.  
  297.  
  298. cpp removes blank lines
  299. -----------------------
  300.  
  301. With the new cpp, you need to add -traditional to the "cpp -P" args, else 
  302. blank lines get removed.
  303.  
  304. [EDIT ME: scan Debian bug reports and write some nice summaries ...]
  305.